开发人员写测试，Google是这样做到的，你想到没有
下面是2010年Google的自动化测试情况，有点羡慕，惊为天人么~~~~
然而，2005年时，却是另一番景象~~~~~~
我就问你，图中的括号亮不亮？
然而，这五年之间发生了下面的事情~~~~
图中的2008，你注意到了么？（文末有Google的相关教程列表）
而今天我说的事情，是发生在这个系列教程的两年前哦~~~~
从2006年初开始，为了鼓励开发工程师做好自动化测试实践，Google的工程师自发地成立了一个专项建设组。其中有一个“测试级别认证（Test Certified）”，在其中扮演了非常重要的角色。
1 Test Certified是什么
———————————————
Test Certified (以后简称“TC”)，包含三级，12步（其实不到12步）。它是自动化测试志愿者组(以后简称 TG)提出来，用于让Google的工程师对代码质量、自动化测试提升意识，提高开发者测试实践能力和代码自动化测试覆盖率。它可以帮助团队建立度量和早期目标，以及必要的承诺，从而快速达到值得注意的结果，并能遵循习惯和规范，最终达到长期代码健康。
Test Certified是2006年Bharat Mediratta和Nick Lesiecki想出来的点子。用TC有两个明显的好处：
（1）团队在测试实践方面提供了抓手；
（2）TG和TM（一定程度上的Test Engineering/EP团队）可以衡量在多大程度上对多少工程团队产生影响，比如通过跟踪有多少团队在爬梯，处于什么级别，每个季度的进展等。
从2007年6、7月份开始，让Google所有工程团队都来升级打怪爬 “TC”天梯 成为TG和测试教练（TM）的具体着力点，甚至整个EP团队的TEs 和SETs都用它来驱动其各自所在的产品团队进行改进。
2 Test Certified 有多少级别
————————————————
Test Certified 最初有三个等级，每个等级下面有很多个小任务。有些小任务可以很快完成，而另外一些需要花一些时间和精力。正如你能想到的那样，每上一个层次都会花费更多的时间和精力来实现。
Level One 主要是有来设置衡量当前事态发展所需要的工具，比如：
（1）建立连续的构建机器和测试覆盖率度量;
（2） 将测试分类为“小”，“中”或“大”
（3） 并识别脆弱测试
这个级别的设计很容易在一两天内由一两名工程师完成。 对于每个团队来说，这是最重要的一套工具和实践。在人们正确进行衡量的情况下，他们往往会自觉地改进测试习惯，即使没有明确运行TC级别。
Level Two 制定书面守则，
（1）从根本上禁止任何人提交未经测试的代码，
（2）以及测试覆盖的目标
（3）把测试从unit和Integration、System改为Small、Medium和Large。
尽管这些具体的数字目标有点争议，但他们只是建议，团队可以使用的指导，并在必要时进行修改。
根据代码或整个应用程序的结构以及证明合理的结果，团队可以直接在第二级进行“认证”，而不秘达到规定的覆盖级别或测试规模比率（详见认证过程）。 Bharat的团队（他负责Google Website Service)所用的TC规范围成了全公司TC规范的模板，它后来成为数百个团队规范的基础 。在这一级别，可能需要花了几个星期或几个月的时间，才能达到测试覆盖目标。
Level Three 指具有一个流畅运行的测试过程，你想象有多流畅，就有多流畅。 基本上，
（1）所有类型的测试覆盖范围持续走高；
（2）覆盖目标是针对某个“规模”的每组测试
（3）失败或脆弱测试的低容忍度。
这个水平代表了一个团队将要努力保持的可持续长期承诺。
后来，又增加了第四级和第五级，其中更加严格的覆盖目标和任务包括静态分析工具等其他工具。
3 Test Certified 是如何认证的
————————————————
认证过程 并不是非常正式的，如下所示：
（1）团队申请一个测试认证的“导师”；
（2）团队有一个志愿者，他已经被灌输了TC梯子的方式和传说，并被认证有能力指导其他人。
（3）这个团队将被指定一个导师，他将亲自与团队协商，让他们开始使用工具，测量和建立规范。 团队偶尔会与导师签协议，反之亦然。
（4）一旦双方都认为达到了某个级别的要求，导师就会提出对该团队进行审查。
（5）一些同行评议之后，共识是团队至少达到了某一级别所倡导的精神，即使没有达到某个确切的数字，团队也会被授予该级认证。
4 如何快速扩展
———————————
好象没法快速扩展，对不对？但是，Google有自己的Google’s build system，开发了一些工具和协议来处理负载。 除此之外，当TG把“让所有工程团队都来爬TC”作为它的主要使命之后，他们还游说EP部门的成员，使用 TC作为一个推手，借此鼓励他们所支持的团队提高他们的代码质量。更好地利用TEs和SETs的时间，让更少的低级别的错误下降。
这个想法最终引起了人们的注意，EP部门成了TC发展和影响背后的巨大力量，提供了大量的志愿者导师，每个新的导师者分担现有的导师一些负担，一个测试认证 及其以后变得更加容易和简单，最终在测试自动化平台（TAP）中达到高潮。
当然，厕所测试Tips（TotT，如下图）也是作为促进TC本身的工具，而且还有测试技术和工具的改进，这样整个公司的TG和团队就可以在一个语景中保持对话，并共享共同的交流词汇，进一步降低了他们之间的摩擦。
TM要为那些最需要帮助的团队提供实际指导，并将工具使用方面的反馈直接提需求给工具团队。
5 让这事情更有趣一些.
—————————————
Google还设计了一个基于TG标志的TC标志，并制作了T恤和咖啡杯，标语是“Arrre you Test Certified？”。同时，还做了一些装满了绿色和红色糖豆的塑料灯泡作为奖品。由Matt Vail和Tayeb Karim组织的TC挑战赛是一个长达数月的Fix-it，鼓励了大量的个人、团队和整个办公室来爬天梯，获得积分，奖品和荣耀。在纽约，David Plass，Prakash Barathan，Catherine Ye，Tony Aiuto等人建造了一座自由女神像监视灯，作为纽约团队获得TC Level One的奖励。
6 总结一下
——————————————
TC超出了它的设计预期。
（1）在大约四年的时间里，大量项目签约参与了TC。
（2）TC还引发了很多的讨论，包括流程变更和工具开发，所以无论产品团队在TC的哪个级别，或者根本没有参与， TC的规范和实践已成为大多数Google工程团队最基本的工程标准程序。
尽管不是所有的团队都达到第三级，但是实际上它让每个工程团队都注意到自己的自动化测试和代码健康，并且希望公司的其他团队也能有更高的标准。
更重要的是，“TC”是由一个自下而上的组织自下而上地提出的，这个组织对任何人都没有任何权力去规定这些流程和规范，但它帮助实现了真正、显著且持久的变化。
在开始时，G仍然需要首席执行官埃里克·施密特（Eric Schmidt）和其他高级管理人员公开并强有力地支持测试认证（TC），并鼓励开发人员测试。
Patrick接着提到他来自微软。而微软、还有Novell和Sun，Digital等公司，当公司对工程师提出类似要求的时候，好像很一次都失败了，希望在Google，这种情况能够不发生。
也并不是没有黑暗面 有些工程师喜欢深陷细节：
“做这个有什么意义”
“你怎么衡量它的有效性”
“什么是重要的，什么是不重要的”等等。
这样的辩论在很多时候激怒一些人，甚至有时候还会上升到更高的管理者来干预。TG领导者也轮换过，值得庆幸的是，还有更多的人用精力、热情、耐心、动力和自制，来应对这些争论。
尽管关于有用性或官僚主义的讨论很讨厌，但是不可否认的是，更多关于TC的标准和目标的讨论（TotT经常交替挑起和总结的讨论）提高了工程师们对开发测试的了解；意识到公司提供可用的技术和工具；当然也包括意识到在选择合适目标，流程和规范方面的复杂性。
最终的欢喜
最终，你看到了现在的Google的样子，工程师们自己衡量和辩论每一段代码的优缺点，并且有意识的做出是否采纳、修改或者拒绝的决定。最终形成一个更完善的代码，以及一个更加普遍的高可维护代码质量谷歌文化。
但请记住，十几年前并不是现在这样的。所以，你还有机会拯救你的同事于水火，拯救你的公司于焦油坑。
下面是2008年Google讲代码质量（易读性、易测性、良好设计）的视频，
做为工程师，你一定能找到~~~~~我就不给链接啦~~~~